Re: [TLS] TLS 1.2 draft comments

[EKR <ekr@xxxxxxxxxxxxxxxxxxxx>]

<home_pw@xxxxxxx> writes:
> 3. RSA CIPHERSUITES WITH NEW KDFs, LOCAL RSA CIPHERSUITES
>
> Does IETF intend to now standardize any RSA ciphersuite that define their
> own KDFs? Or is IETF going to limit itself to only addressing ciphersuites
> that use the TLS PRF as a KDF?
>
> The following text may need updating, as KDFs per ciphersuite now may
> or may not be using (in the handshake layer) "HMAC, keyed MACs, or
> secure digesting of data that is protected by a secret"
>
> "A number of operations in the TLS record and handshake layer required
>   a keyed MAC; this is a secure digest of some data protected by a
>   secret. Forging the MAC is infeasible without knowledge of the MAC
>   secret. The construction we use for this operation is known as HMAC,
>   described in [HMAC]."

Yes, I'll clean this up.


> 4. AEAD
>
> I still don't understand the objective for introducing AEAD. It seems to
> exist to provide a explicit data origin authentication service tied a
> confidentiality
> service.

I would advise you to read draft-mcgrew-auth-enc-01, which describes
the rationale for this kind of primitive.


> Unlike the DOA that traditionally provided by assured
> writer-to-reader
> confidentiality service, the implied DOA is then tied to the error
> signaling in
> and of the record layer.

Huh? Data origin authentication failures in TLS always occured at
the record layer. We're just replacing two algorithms at the
record layer with one.


> (a) can the DOA properties of non-AEAD-based confidentiality services
> also be tied
> to the (authenticated) error signaling

I don't know what this means.


> (b) once the AEAD internal error state is detected on the read
> subchannel, does the
> standard intend the encryption mechanism in the HSM to stay active,
> ... so it can
> now be used authenticate/encrypt/DOA the fatal alert on the write
> subchannel?

The behavior here is exactly like it always has been for TLS.
You generate a protected MAC on the write channel and then 
abort. (Note that DTLS behaves differently since MAC errors
are not fatal.)


> c) is it non-conforming for an AEAD cipersuite to specify a NULL MAC
> component?
>
> We need an authoritative reference for AEAD, not just some I-D.

Yes. This creates a normative dependency on that I-D.


> All
> this draft
> document chasing is like Tom chasing Jerry chasing Tom, right now. I assume
> with AEAD added, TLS will now have to stay at Proposed for 7 more
> years... till
> we understand its impact.

TLS staying at Proposed for 7 years had to do primarily with 
WG inertia. And the reason that 1.2 will not go to Draft is
that we are making major technical changes.


> 5.PKIX
>
> 7.4.2 "All certificate profiles, key and cryptographic formats are defined
>   by the IETF PKIX working group [PKIX]."
>
> This needs to go. TLS1.2 introduces non X.509 certificates, very
> clearly. And,
> one assumes PKIX WG has to die one day, too. We don't want references to
> working groups in standards.


The reference is to an RFC.

   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
            Public Key Infrastructure: Part I: X.509 Certificate and CRL
            Profile", RFC 3280, April 2002.

-Ekr

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls