RE: [NSIS] TLS in the GIST draft

Robert Hancock wrote:

> hi pasi, john, all, 
> 
> [warning: long, dense mail] 
>
> i've had time to think about this a little. in terms of what one
> could specific about TLS, there seem to be 4 (related) issues, all
> of one it would be good to see some more discussion on.
>
> 1. TLS version. The draft currently says MUST 1.0, SHOULD 1.1.
> Given that GIST will be built from TLS libraries (rather than
> already deployed TLS code), maybe we could be more prescriptive
> about wanting 1.1; would that be a good or bad thing?

Many existing TLS libraries don't support 1.1 yet, and since the
improvements in 1.1 are really minor, I don't see why we should
require it.

> 2. Cipher suites (raised earlier in this thread). AFAICT from
> reading them, the TLS documents specify a single (mandatory to
> implement) cipher suite, so TLS compliance is enough to provide
> interoperability from that point of view. Is there a need to be more
> prescriptive here? (Why did Diameter do so?)

The mandatory-to-implement ciphersuite specified in RFC 2246 is
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. This can't be used in 
many situations because it requires certificates containing DSS
public keys (most certs are RSA).

TLS 1.1 changes this to TLS_RSA_WITH_3DES_EDE_CBC_SHA, which 
is slightly better. But IMHO it is still worthwhile to clarify 
this explicitly in the NSIS specs, especially if we do not
mandate 1.1.

> 3. What authentication methods (certificates, EAP, SRP, etc.  etc.)
> should be implemented. (Sometimes the authentication method seems to
> be implied by offering a certain special ciphersuite, as in the PSK
> case in particular.)

The ciphersuite does imply something about the authentication,
but not necessarily everything that's needed. But if we copy the
Diameter text, it pretty unambiguously talks about mutual
authentication using certificates.

> 4. How to decide which identity is to be asserted and authenticated
> (of querying and responding node
>
<snip>
>
> Even if we do stick with the NLI, there may still be a need to write
> something about operational issues. That could be to encourage some
> uniformity in the selection of authentication techniques, and also
> (maybe) proposing a structure for the PI field in the NLI (if only
> to make it human-readable).  That might be for the GIST spec itself,
> or (more likely?)  for some separate BCP-like thing.

If it's required for actual interoperability, then it IMHO needs
to be in the GIST spec (or if it's a separate document, the GIST
spec will need a normative reference to it)... but I guess
it depends on the ambition level. It seems that for certificates,
this isn't really an issue, so copying the Diameter text would
be fine.

Best regards,
Pasi

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis